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ABSTRACT 



A method, computer program product and a program storage 
device embodying software for measuring of the response 
time of an application (including distributed applications in 
a client/server or Internet environment) as perceived by an 
end-user. One aspect deals with the measurement of com- 
ponents of the response time and relating those components 
to user response time. In addition, the components of one 
transaction can be matched (or correlated) to each other even 
though they are measured on different systems. The genera- 
tion of events and transactions can be controlled, allowing 
their creation to occur as close to their point of origin as 
practical. Both aggregate and detail reporting facilities pro- 
vide overall performance and availability information as 
well as exceptions and/or detail transactions including the 
decomposition of overall availability and performance met- 
rics into smaller measurements representing the contribution 
made by select transaction components. An interactive 
reporting facility enables the selection of a level of trans- 
action decomposition desired. This enables the identification 
of the transaction components that are introducing delays or 
faults. The system is extensible, enabling the addition of 
components to the system that extend its measurement and 
reporting capabilities. In particular, a language has been 
created to facilitate the definition of the end-to-end business 
application transactions. Also, select APIs as well as appli- 
cation data structures allow the addition of software and/or 
hardware modules to extend the system. The system can also 
adapt to the presence or absence of select streams of events 
without having to change its mode of operation. Measure- 
ment sources that generate events can be dynamically acti- 
vated and deactivated. 



http: //www. vital signs.com/product/netmedic_pre view/in- 
dex .html, "NetMedic", Product Preview, Vital Signs Soft- 
ware. 
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APPLICATION END-TO-END RESPONSE 
TIME MEASUREMENT AND 
DECOMPOSITION 

HELD OF THE INVENTION 

This invention generally relates to the Service Level 
Management (SLM) field where programs measure the 
performance, utilization and availability of computers or the 
work done by computer applications. A more particular 
aspect is related to measuring the response time of a user 
transaction and relating it to the expected response lime. 

BACKGROUND OF THE INVENTION 

End-to-end response time ("ETE RT'*) refers to the time 
a user experiences in interacting with a computing system. 
It is typically the duration between the start of a user's 
request (e.g., indicated by depressing a key or a button) and 
the time when the user can use the data supplied in response 
to the request. Thus, end-to-end response time represents a 
user orientation in performance management as contrasted 
with resource oriented performance metrics such as CPU 
utilization or I/O rate. 

ETE RT bridges the business and technical worlds. On 
one hand, the end-to-end response time of a transaction can 
be associated with a business transaction performed by the 
application. On the other hand, end-to-end response time of 
a user transaction is also related to the resources consumed 
by the transaction. Thus, ETE RT serves a very important 
link between the business understanding of computer use 
and the technical understanding of the system (see e.g., 
Richard S. Ralston. In Search of End-to -End Response 
Time. Computer Measurement Group Conference 
Proceedings, December 1995). 

ETE RT is available and is used today to some degree in 
a mainframe environment. For example, combined CICS/ 
VTAM, two subsystems of MVS, have such a facility (see 
"CICS/ESA Performance Guide for Release 4.1," IBM 
Corporation, 1996, SC33-1183-00). However it works only 
on those subsystems and provides no decomposition mea- 
surement or correlation. The NetView Performance Monitor 
(NPM) product allows measurement of total ETE RT in an 
MVSA^AM environment for some limited circumstances 
(see "NetView Performance Monitor" (NPM), IBM Corp., 
Product Number 5665-333. Manual GH19-6840-01). NPM, 
which is terminal-based (unlike the client/server 
environment), does not decompose this total time. ETE RT 
is just emerging in a client/server environment. Despite the 
importance of ETE RT, there are surprisingly few estab- 
lished products to measure it. This is one indication of the 
degree of technical difficulty to produce such a facUity. 

The Application Response Measurement API and SDK 
(available from the Hewlett-Packard and Tivoli WebSites 
(http://www.hp.com/go/arm and http://www, tivoli. com/ 
ARM) define and support an API that allows indication in an 
application of when a transaction starts and when it com- 
pletes. The ARM API is supported by products such as those 
by Tivoli Systems under the trademark TIVOLI 
REPORTER (see http://www.tivoli.com) and by Hewlett- 
Packard Corporation under the trademark MEASURE- 
WARE (see http://www.hp.com)). Neither the ARM API nor 
these products have the capability to measure components of 
response time and aggregate those components into a per- 
formance profile of each transaction. 

Another product, sold by VitalSigns Corp. under the 
trademark NET.MEDIC (see http:/Avww.vilalsigns.com), 
allows the measurement of response time at an Internet 
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browser. It does not do measurements of the server computer 
and performs no correlation. 

Still another product, sold by Candle Corporation (http:// 
www.candle.com)] under the trademark ETEWATCH, mea- 
5 sures the total response time of an Internet browser but 
provides no decomposition of the response time. 

Yet another product, sold by Computer Associates Corp. 
under the trademark NETSPY, captures packet headers and 
provides a measurement of ETE RT for a limited set of 
standard applications. It uses certain assumptions (perhaps 
incorrect) about a packet's content and order for those 
applications. The product does not provide decomposition of 
ETERT. 

Another product, sold by the Network General Corp. 
under the Trademark SNIFFER, allows A comprehensive 
collection of network traffic (packets) and a fairly large set 
of analysis programs. Some of those programs provide an 
indication of ETE RT. In general, it is a network traffic 
analyzer and has a limited ETE RT capability. The product 
does not provide decomposition of ETE RT. 

ETE RT measurement is one of the key measures of 
service levels provided by the computing equipment. In 
many companies ETE RT is tracked at the executive level 
(especially in the case of CICS). 

This is how user satisfaction is measured. When comput- 
ing equipment is upgraded, the improvement in ETE RT 
serves as one indication of the effectiveness of the upgrade. 
The client/server environment in general is more end-user 

3Q oriented. Also, the equipment in this environment comes in 
less expensive units, which tends to reduce the importance 
of resource oriented measurements. Thus the introduction of 
ETE RT measurements and the methodology of its use in 
client/server environment are of significant business interest 

35 (see "Distributed Client Server End-to -End Response Time: 
Instrumentation, Methodology and Experience," by Mark 
M. Maccabee, Anna Lx)ng, and Walter Schwane, Computer 
Measurement Group Conference Proceedings, December 
1995.; and "Client/Server End-to-End Response Time: Real 

4Q Life Experience," by Mark M. Maccabee, Computer Mea- 
surement Group Conference Proceedings, December 1996. 
Since the clien^server environment is relatively new and not 
well understood, introduction of an ETE RT facility presents 
a significant technical challenge. 

45 Once the user response information is available to users, 
their interest shifts. They want and need more details about 
the user transaction (to decompose it). In client/server 
systems, for transactions deemed to take too much time, the 
user wants to how much of the time was spent in the client, 

50 in the network and in the server. This need comes from the 
underlying business question: since the system is too slow, 
which of its three main components needs to be worked on 
(to tune it, to fix it, to upgrade it). 
There are patents directed to various aspects of response 

55 time. For example, U.S. Pat. No. 5,504,894, entitled "Work- 
load Manager for Achieving Transaction Class Response 
Time Goals in a Multiprocessing System" does not provide 
ETE response time measurements. Rather it measures the 
server (mainframe) component of response time and claims 

60 to improve it automatically. U.S. Pat. No. 5,428,789, entitled 
"Method and Apparatus for Optimizing User Response Time 
in a Priority Preemptive Operating System" similarly is 
directed to improving response time rather than measuring 
and decomposing it. 

65 U.S. Pat. No, 4,369,493, entiUed "Response Time Moni- 
tor" describes a hardware system that tracks the character- 
istic of a computer terminal to measure ETE RT. It does not 
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deal with decomposition. The value of terminal based mea- The present invention has still other features which pro- 

surement facility such as this is greatly diminishing because vide such a system with extensions enabling customers and 

of the move to more modem workstations. other developers to add components to the system that 

Thus, there is a need for an improved method and system extend its measurement and reporting capabilities. In 
for measuring and reporting availability and performance of s particular, a language has been created as part of this 

end-to-end business transactions. There is also a need for a invention to facilitate the definition of the end-to-end busi- 

means to copy or derive information necessary for correlat- ness application transactions. Also, select application pro- 

ing and collating select measurement events into transac gramming interfaces (APIs) as well as application data 

tions that describe the behavior of end-to-end business structures (ADS's) belonging to the system will be docu- 

transactions as it appUes to availability and performance mented to permit the addition of software and/or hardware 

metrics. There is a further need for the system to correlate modules to extend the measurement and/or reporting facih- 

and associate transactions occurring at different measure- system. 

ment points within the path taken by a business transaction ^^^^ .^^^^^^^ j^^^ ^^^^^ ^^^^^^^ ^^.^^ 

so ayailabihty and performance can be assessed at select ^.^^ ^^^.^^ .^^ ^^^^ management whereby the absence 
pomts along the path, decomposing the overall availability ^5 measurement events is tolerated by system and the 

and performance into Its component parU at or between transactions it generates remain valid, but do not include the 

these select pomts. The present mvention addresses these ^^^^^ information. This enables the system to adapt to the 

^' presence or absence of select streams of events without 

SUMMARY having to change its mode of operation. Customers or other 

In accordance with the aforementioned needs, the present developers can dynamically add measurement sources that 

invention is directed to an improved method and system for generate events and the system will accommodate the new 

measuring and reporting availability and performance of arrival of these events without adverse affects, 

end-to-end business transactions. In one embodiment of the present invention there arc 

The present invention has features which enable the ttiree stages of activity; Event Generation, Transaction 

derivation of information necessary for correlating and Generation, and Report Generation, as well as an overall 

collating select measurement events into transactions that management of the System accomplished through System 

describe the behavior of end-to-end business transactions as Admmistration. 

it applies to availability, performance (response time). Business Transactions range from the very simple, to very 

capacity, and utilization metrics. An example of the appli- complex. A business transaction may include a single direc- 

cation to availability is that transactions can be formed even tive where one system "tells" another to do something 

if not aU the events are available. An example of the without soliciting a response. An example might be having 

application to system capacity is that since the duration of a a system broadcast the current stock price for a given 

single event can be measured, the number of events per unit company. A business transaction may include multiple dircc- 

time can also be calculated. An example of the application lives each of which may or may not require a response where 

to system utilization is that once the number of transactions one system tells several other systems to do something and 

per unit time are known, this can be compared to a maximum depending upon the responses, it continues to solicit actions 

number of transactions per unit time. to be taken by systems in order to complete the desired 

The present invention has other features which can cor- affect. An example might be having an order taken update 
relate and associate transactions occurring at different mea- 40 the inventory and customer credit information, 
surement points within the path taken by a business trans- End-to-end business transactions represent all the pro- 
action so availability and performance can be assessed at cessing stages (e.g., directives and responses) that comprise 
select points along the path, decomposing the overall avail- the business transaction as events contained within one or 
ability and performance into its component parts at or more associated transactions. This invention measures these 
between these select points. 45 processing stages and the communications between them by 

The present invention has still other features which can using Sensors, 

control generation of events and transactions, allowing their Sensors monitor for select changes in state using a variety 

creation to occur as close to their point of origin as practical, of methods to glean which activities are being achieved: 

thereby reducing data volumes and distributing system insertion of probes; registration for callback on select exits; 
workloads as widely as possible, minimizing impact on the 50 or interception of directives and responses issued by the 

communications and storage requirements for the system, activity. Sensors compare the changes in state against rules 

and minimizing impaa on the business transaction compo- used to generate events. If the change in state is such that an 

nents the system is measuring. event can be generated, the Sensor further checks control 

The present invention has yet other features which can rules (e.g., filters) to detennine if it may generate the event, 
provide both aggregate and detail reporting facilities to 55 When appropriate, the sensor generates an event that 

enable customers to glean overall performance and avail- describes the change in state, when and where it has 

ability information as well as to examine exceptions and/or occurred, and any extra data necessary to uniquely identify 

detail transactions including the decomposition of overall the event (e.g., an event describing that a file has been 

availability and performance metrics into smaller measure- opened might include the name of the file as well as the file 
ments representing the contribution made by select business 60 handle returned by the open activity for use in subsequent 

transaction components. file accesses). An event contains a time-stamp and correla- 

The present invention has other features which provide tion data used later by the system to associate the event with 

interactive reporting facilities enabling customers to select other events into transactions. Examples of correlation data 

the level of transaction decomposifion they wish to view. include but are not limited to one or more of an IP address, 
The interactive reporting facilities enable customers to glean 65 Socket ID, file handle, database name, document number, 

which business transaction components are introducing user ID, machine ID, process ID, thread ID and application 

delays or faults that adversely affect the business transaction. ID. In other words the correlation data can be any data which 
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represent a common thread running through a transaction transactions, as well as the sorting and aggregation methods 
and which, according to the present invention, can be used used to consolidate the transactions' event data into avail- 
to associate the event with other events into transactions. ability and performance information. 

Sensors forward the events they generate to their Agents 

for temporary storage and distribution to other system 5 BRIEF DESCRIPTION OF THE DRAWINGS 

components that have registered interest in knowing that a • j . • r , . 

select event has occurred One such process is the (Event) -I^? ^^^f '"f other objects, features and advantages 

Processor. The Processor is also an event generator using better understood from the foUowmg detailed 

rules and controls like the Sensor, except it determines description of the invention with reference to the drawings 

changes in state by analyzing events instead of directly jq wherein: 

monitoring activities taken by business applications or the FIG. lA depicts an ETE Service Level Management 

platform components on which they run. Processors gener- System (SLMS) Example Transaction; 

ate events that may result from (but are not limited to) FIG. IB depicts an example of an ETE (SLMS) Event 

aggregations of events (e.g., start of batch of sends, end of Generation according to the present invention; 

batch of sends), or from series of events (e.g., first open, last ^5 pj^. ic depicts an example of an ETE SLMS Transaction 

close), or from further analysis of the correlation data within Generation according to the present invention; having fea- 

events (e.g., open of networked file vs. open of local file). tures of the present invention; 

Processors also forward the events they generate to their ^-t/-. it> j • * 1 r ot ^^^^ 

. , • p ™, *• ' ^ . u FIG. ID depicts an example of an ETE SLMS Report 

Agents. Because no new information is added to the sys- ^ » ♦u . • *■ 

, ^ , ^, ^ ^. Generation according to the present invention; 

tem once events are formed, the event generation used by or 

sensors and processors must copy data from application ^ *^^Pi^^ ^° example of an ETE SLMS System 

data, or must derive their own data based on event analysis Overview according to the present invention; 

(e.g., aggregate data might be derived) and place this data FIG. 3 depicts a more detailed example of the ETE SLMS 

within correlation data belonging to events. Event Generation; 

Another system component that may register for events is 25 FIG. 4 depicts a more detailed example of the ETE SLMS 

the Transaction Generator. Just as Sensors and Processors Transaction Generation; 

use rules and controls to glean whether they can and may piG. 5 depicts a more detailed example of the ETE SLMS 

generate events, the Transaction Generator uses rules and Report Generation; 

controls to glean whether it can and may generate transac- pj^. 5 depicts a more detailed example of the ETE SLMS 

tions. The Transaction Generator is managed by a Director 30 Administration* 

that communicates with Agents to retrieve select events , ' , ^ ^ 1 

needed by the Transaction Generator to generate transac- ^ f^P^^^ ^^^"^P^^ describes the flow of 

tions. Events retrieved by the director are presented to the execution from sensing change in the application until 

Transaction Generator who in turn assesses the content of transactions are placed in the Transaction Store; 

the event (e.g., time-stamp and correlation data) to deter- 35 FIG. 8 depicts an example of the flow of execution from 

mine if the event should begin a new transaction, and/or if ^ transaction definition until this definition is converted to a 

the event should be incorporated within an existing "work- set of rules that can be used by the Transaction Generator; 

in-progress" transaction. The rules used by the Transaction FIG. 9 depicts an example of the flow of execution from 

Generator originate in a human readable language format user's request for a report or continuous monitoring until 

that is later converted into binary format capable of being 40 this request is satisfied; 

interpreted by the TransacUon Generator. Transactions are piQ. 10 depicts an example of the flow of execution 

collations of correlated events, and contain the events as during a Transaction Generation; 

well as the "links" that show the relationships among these pjQ ^ ^ .^^^ ^ g^^^^ ^^^^^ 

events. Based on the transaction generation niles, and the ^.^ , . . , ^ . . , „ 

arrival of events, when a transaction is completed (e.g., no 45 " '^P''^'^ '° ^"^^^^ °^ ^ CorrelaUon Vanable ID 

longer "work-in-progress") it is presented to the Director Kecora, 

where it is temporarily stored pending distribution to other FIG. 13 depicts an example of Link ID Records; 

system components that have registered interest in knowing FIG. 14 depicts an example of a Browser Response Time 

when select transactions have been generated. and Decomposition; and 

One such system component interested in transactions is 50 FIG. 15 depicts examples of ETE APIs according to the 

a Transaction Store. The Transaction Store is maintained by present invention, 
a Manager that communicates with Directors to retrieve 

select transactions. The Transaction Store is a repository for DETAILED DESCRIPTION 

transactions and maintains them in their original state as FIG. lA depicts an example of a client-server application 

well as storing aggregate records built from transactions. S5 architecture with which the features of the present invention 

These aggregate records are in support of the Report Gen- can interact to produce information. As depicted, a client 

eration facilities of the System as described further on in this (100) is used to initiate a request, for example via keyboard 

narrative. The Transaction Store may also work with other (105). Requests, however, could be initiated by any conven- 

Transaction Stores to manage their transactions in a manner tional means such as by mouse click, voice command, bar 

that expedites report generation. 60 code swipe, etc. Examples of the client (100) are personal 

Report Generation involves the retrieval and manipula- computers, kiosks, data entry terminals, scanners, 

tion of transactions to glean information relating to avail- telephones, pagers, etc. The request is acted upon locally 

ability and performance of business transactions. Just as (HO) where the request is formulated and forwarded to an 

event and transaction generation used rules and controls in application server (120) via a network (115). Examples of 

the creation of their output, so do the Report Generation 65 the network (115, 140) and communication protocol are 

facilities of this invention. Generation of reports includes socket-based communications riding on TCP/IP transport 

definition of the initial selection and processing of across a local area network (LAN) that is connected by 
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router to a wide area network (WAN) containing many 
switching locations that create a virtual circuit to a service 
provider and eventually to an application server. Examples 
of the application server (120) are high-end personal 
computers, RISC-based PowerPC's, UNIX-based 
workstations, minicomputers, or mainframe computers run- 
ning software fielding requests from clients and distributing 
the requests to appropriate back-end database servers when 
appropriate. For discussion purposes we will describe an 
electronic commerce transaction initiated within a web 
browser to purchase an item using the Internet (note, how- 
ever that the invention is intended to work with any form of 
transaction). Examples of web-based application servers 
include, but are not limited to those sold by Microsoft under 
the trademark INTERNET INFORMAnON SERVER, by 
SAP under the trademark SAP R3, or by Lotus under the 
trademark LOTUS NOTES SERVER. 

In the example transaction, the application server (120) 
processes the request (125) and accesses a local database 
(130) to provide authentication and/or identification of the 
client (100). The application server (120) analyzes (135) the 
data returned from the database (130) and once determining 
the client may proceed with the purchase, communicates 
another request via a network (140) to a database server 
(145) to decrement inventory. The database server (145) 
processes the request (150), accesses its database (155) and 
prepares a response (160) to the application server (120). 
Examples of database servers include, but are not limited to 
those sold by Microsoft under the trademark SQL/SERVER 
or TRANSACTION SERVER and by IBM under the trade- 
mark DB2 SERVER. 

The application server (120) receives the response (165) 
from the database server (145) and returns it via the network 
(115) to the client (100). The client then processes the 
response (170) to format it for display and presents the 
response (175) for the transaction initiator to review. 

FIG. IB depicts the system of FIG. lA including features 
of the present invention for generating events (205). As 
depicted, sensors (200) interact with the software and hard- 
ware components through which the business transaction is 
processed, gleaning changes in state that result in the gen- 
eration of events (205). Examples of sensors include soft- 
ware written to interact with software exits by registering for 
notification of select conditions (e.g., Lotus Notes Extension 
Manager); software and/or hardware written to intercept 
activities taken by the business transaction's software and/or 
hardware (e.g., interception DLL's or shared libraries, or 
analysis of output logs or alert messages); or insertion of 
software and/or hardware probes within the business trans- 
action's software and/or hardware (e.g., ARM API calls 
within business transaction source code). If the change in 
state is such that an event can be generated, the Sensor 
further checks control rules (FIG. 2) e.g., filters to determine 
if it may generate the event. When appropriate, the sensor 
generates an event that describes the change in state, when 
and where it has occurred, and any extra data necessary to 
uniquely identify the event (e.g., an event describing that a 
file has been opened might include the name of the file as 
welt as the file handle returned by the open activity for use 
in subsequent file accesses). 

In addition to descriptive information about when (such as 
a time -stamp) and where the change in state occurred, events 
also include (for example via event records) any additional 
correlation data useful for later associating the event with 
other events to form transactions. Sensors (200) forward the 
events they generate to their Agents (FIG. 2) for temporary 
storage and in certain cases distribution to other system 
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components that have registered interest in knowing that a 
select event has occurred. One such process is the (Event) 
Processor (210). The Processor (210) is used to analyze 
events (205) to further deduce changes in stale. These 

S changes in state may be directly related to actions occurring 
within the business transaction's software and/or hardware 
or may be derived by combining previously generated 
events from Sensors (200) or other Processors (210) to 
describe states achieved. For example, a processor could be 

10 used to describe the change in state from no databases being 
accessed to at least one database being accessed. Another 
state might indicate the end in a series of like events (e.g., 
the end of a transmission marked by the last send event 
preceding a receive event, or closure of the communications 

]5 channel event). Thus, the Processor (210) can also be an 
event generator, using rules and controls (FIG. 2) like the 
Sensor, except it determines changes in state by analyzing 
events instead of directly monitoring activities taken by 
business applications or the platform components on which 

20 they run. Processors can generate events that may result 
from (but are not limited to) aggregations of events (e.g., 
start of batch of sends, end of batch of sends), or from series 
of events (e.g., first open, last close), or from further analysis 
of the correlation data within events (e.g., open of networked 

25 file vs. open of local file). Processors also forward the events 
they generate to their Agents (FIG. 2). 

FIG. IC depicts an example of the events (205) being 
correlated and collated with transactions (305) based on 
logic contained within transaction generation rules (300). An 

30 event contains a identifying information such as a time- 
stamp and conelation data subsequently used by the system 
to associate the event with other events into transactions. 
Correlation data can be any data deemed to be appropriate 
for later event correlation and collation within Transaction 

35 Records, and/or for report generation (e.g., to service selec- 
tion requests for specific transaction records). Transactions 
are collections of related or linked events and/or other 
transactions. The event correlations (305) are based on 
common data attributes (correlation data) found within the 

40 events (205). Events can be assessed to determine if the 
event should begin a new transaction, and/or if the event 
should be incorporated within an existing "work-in - 
progress" transaction. It is a major advantage of the present 
invention to perform the correlation and collation of events 

45 in a dynamic fashion, dictated by flexibly defined transac- 
tion generation rules (300) that can be created and/or 
changed. Preferably, the rules originate in a high-level 
software language format that is later converted into a binary 
format capable of being interpreted by a transaction genera- 

50 tor (FIG. 4). Transaction definition and transaction rule 
generation will be discussed in more detail with reference to 
FIG. 8. Based on the transaction generation rules, and the 
arrival of events, when a transaction is completed (e.g., no 
longer a "work-in-progress") it can be temporarily stored 

5S pending distribution to other system components that have 
registered an interest in knowing when select transactions 
have been generated. 

FIG. ID depicts an example of Report Generation (400) 
facilities having features of the present invention. By way of 

60 overview, Report Generation (400) involves the retrieval 
and manipulation of transactions to glean information relat- 
ing to availability and performance of business transactions. 
Just as event and transaction generation preferably uses rules 
and controls in the creation of their output, so do the Report 

65 Generation facilities. Generation of reports includes defini- 
tion of the initial selection and processing of transactions, as 
well as the sorting and aggregation methods used to con- 
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solidate the transactions* event data into availability and (565), a report or continuous graphical monitoring can be 

performance information. As depicted, the Report Genera- produced for the Infonnation Consumer. The Report/GUI 

tion (400) facilities can retrieve transactions from a trans- (565) function relies on the Navigator (560) to find the 

action store (310) and present them in both printed (405) and necessary transactions in TxStore (555). 
interactive (410) formats. The report generation facilities S FIG, 3 depicts a more detailed example of the Event 

enable transactions to be viewed (415) as graphical aggre- Generation logic of FIG. 2. As depicted, the Sensor (510) 

gates or in detailed decomposition's showing the contribu- monitors a System Activity by means of a System State 

tioQ of select stages of processing the business transaction Analyzer (605). Whenever the System State Analyzer (605) 

has undergone. An example of a browser response time and detects a change in state, the Event Generator (600) may 
decomposition will be described with reference to FIG. 14. lo generate an event based on EventGenRuIes (520) and Even- 

HG. 2 depicts an example of a system overview in GenControls (525) Tins evenU^^^^^ 

accordance with the present invention. As depicted, the ^^ich is part of the Agent (505). The Event Store (625) 

system includes three logical components: Event Generation "deludes an Event RegiStratiooADistnbution (630) function. 
(501); Transaction Generation (502); and Report Generation ^^^bonzed hinction can reg^ter for events of mterest 

(503). In the most general view the invention monitors a is (subscribe) and receive a copy of those Agent events^ The 

System (e.g., application) using sensors (510) and provides registered function can be either remote (on a different 

a Report/GUI (565) to the Information Consumer. The computer) or locaL An example of a local funct 

communication among the components can be done in the 'l^^^^^'^^ ^^^j^^ Event Store (625) is the Pro^ssor (515) 
following way. The Agent (505) in the Event Generation ,\^,^^vent Subscription (620) Tht Event State 

(501) component communicates with the Director (530) in ^0 Analyzer (610) examines the events Whenever a change in 

the Transaction Generation (502) component and the Direc ^^^^^ state occurs the Event Generator (600) can produce a 
tor (530) communicates with the Manager (550) in the ^^^f on the EventGenRuIes (520) and the 

Report Generation (503) component. Hie Agent, the Direc- EventC^nControls (525). The event is sent to the Event 

tor and the Manager are preferably controlled by the System ^tore. The System Admimstrator (500) controls the event 
Administrator (500). The Event Generation (501) compo- 25 generation process (determining what events to generate, 

nent preferably exists on every computer being measured, supplying the EventGenRuIes, etc.). 
with one Agent (505) per computer. There can be multiple ^ ^^P^*^^ ^ "^^^^ detailed example of the Transaction 

Sensors (510) and Processors (515) in a computer. The Generation logic of FIG. 2. The events are communicated to 
Sensor (510) monitors and records events according to Director (530) from the Agents by means of the Event 

EventGenRuIes (520) and EventGenControls (525). The 30 Registration/Distribution mechanism (630). The Director 

Sensor sends the events to the Agent (505). Using Event- (530) subscribes to events he needs from Agents using the 

GenRules and EventGenControls the Agent (505) deter- Event Subscription (620) functionality. The Transaction 

mines whether to send the event to the Processor (515). ^^^^ Processor (700) processes the events. The Event 

™ „ r n 1 /eiA\ J Correlation/Collation (705) functionahty uses TxGenRules 

The Processor (515) uses EventGenRuIes (520) and /<^a\ T^i-.^„r-^«*,\io/<^c\ tv«„<. 
- ^ . 1 r . r r j j 35 (540) and TxGenControls (545) to proccss thc evcnts. Tfaus- 

EventGenContro Is (525) to form new events from forwarded ^ .. ' . j u *u V f * /cac\ 

, ™ „ /^^ffx .1 J . . actions generated by the Transaction Generator (535) are 

events. The Processor (515) then sends those new events to . .f' tv„„c„^*;;^« \yro„.„^, /Tift\ fu« i^can\ 

A . Ti r \_i • ^ • i_ x scnt to tfac uausaction Manager (710) in thc DiTector (530). 

the Agent (505). Preferably, the communication between the , l . ~i j c 

J * J i_ . n The transactions can be stored and a copy or some of those 

^}?^ *f I between the Processor ^ent out using the Transaction Registration/ 

(515) and the Agent (505) IS done by means of inter process i^ - , -i /^ia\ r t-u • * c 

• /Tr.A • • TTir- ■ 11 1 4Q Distribution (720) function. The registration for receiving 

communication (IPC) in mam memory. IPC is well known , ,. u f 4U ^ 

, r 1 i; • J £ * *u • transactions can be done by means of the Transaction 

to those of skill in the art and refers to the ability in a „ u • ^n. c / aj • • . * /enA\ 

1.-. 1 • /^o r .1 . L J * Subscription (725). The System Administrator (500) con- 

multitasking OS, of one task or process to exchange data .i-r r> u\* 

-.L I r Tr»^ J • 1 J trols Transaction Generation by determming what transac- 

with another. Examples of common IPC methods include , . . . rr Ti ^ , 

, \ . J * 1 tions to generate, supplying the TxGenRules, etc. 

pipes, semaphores, shared memory, queues, and signals. - , . i-^ ^ , ' , „ 

' ^. „ \ \ . /^«^x FIG. 5 depicts a more detailed example of the Report 

Tlie Director (530) collects events from the Agent (505). Generation logic of FIG. 2. As depicted, the Manager (550) 
The Transaction Generation (502) logic can exist m every Transaction Subscription (725) to subscribe to 

monitored computer but typicaUy it exists in one computer ^^^^.^^ transactions from Directors (530). The Transaction 

m a I^. TTie Director (530) receives evente from the Subscription (725) contacts the Transaction Registration/ 

Agents (505) under his control (the Director can for example distribution (720) to start receiving transactions. The trans- 

have a bst of his Agents . The Transaction Generator (535) ^^^-^^ ^^^^ ^^^^ ^ ^^^^^ ^^^^^^ 

examines the events collected by the Director Transaction j,^^^^^^^ store (555). The Infonnation Consumer can 

Generator (535) uses the TxGenControls (545) and TxGen- ^ ^^^^-^^ ^ ^^^^-^ ^ (g^g^ ^^^^^ 

Rules (540) to produce transactions which are often made of interactive Analysis (850), Tliose two forms of user inter- 

previously generated subtransactions. ^^^.^^ ^^^^ ^ ^^^^^^ P^^^^^^^^ ^^^^y j^^p^^ P^^_ 

The System Administrator (500) determmes (controls) matter interacts with the Transaction Record Aggregator 

what transactions to generate. The System Administrator (goO). For example, Transaction Record Aggregator can 

(500) also detennines what events are generated at the Agent summarize individual transaction records into aggregate 

(505). The System Administrator can also determine the records, e.g. average, distributions. An Aggregator can be 

events that are needed by Transaction Generator (535) lo scheduled or run as a batchjob. Report Formatter can call for 

produce the transactions of interest and limit the events certain types of aggregation or reference existing transac- 

coUected at the Agect(s) (505) to just tiiose necessary for tions. Report Formatter controls the interpretation and prc- 

these transactions. sentation of transaction information, e.g. duration and 

The Manager (550) collerts the transactions from the decomposition. The Transaction Record Analyzer (805) 
Director (530). There can be multiple Directors the Manager 65 requests and receives transactions from the Navigator (560) 

collects from. The Manager stores the transactions in TxS- and combines those transactions into reports by using the 

tore (555). Upon a specific or periodic request a from GUI RptGenRules (810) and the RptGenControls (820), The 



11/06/2003, EAST Version: 1.4.1 



6,1( 

11 

Navigator acquires transactions by retrieving transactions 
directly from Transaction Store (555) by using the Transac- 
tion Requestor (825) or by requesting the Transaction Navi- 
gator (830) to find those for him in the Transaction Store. 
The System Administration (500) controls Report Genera- 
tion by supplying RptGenRules, RepGenControls, etc. 

FIG. 6 describes a more detailed example of the System 
Administration logic of FIG. 2. As depicted, the System 
Administration (500) includes of a System Control (900) 
component and System Configuration (905) compnent. the 
System Control (900) provides the EventGen Controls (525), 
TxGenControls (545) and RptGenControls (820) (whose 
function was described in FIGS. 3, 4 and 5). Among other 
functions the EventGenControls (525) enable the dynamic 
activation of additional events by a sensor and/or the deac- 
tivation of events by a sensor. The System Configuration 
(905) supplies the EventGenRules (520), the TxGenRules 
(540) and RptGenRules (810) (whose function was 
described in FIGS. 3, 4, and 5). The EventGenRules (520) 
are produced by EventGen/Rule/Gen (930) and rely on a 
EventDef Script (935) and on a Event Definition (940) as 
well as a Correlation Variable Definition (945). The Event 
Definition (940) relies on the Correlation Variable Definition 
(945). The TxGen Rules (540) are produced by TransGen/ 
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Rules (54) to collect events into transactions, in step 1050, 
The Transaction Generator (535) then forwards the transac- 
tion to Transaction Store (555), in step 1060. 
FIG. 8 describes an example of a flow of execution from 

5 a transaction definition until this definition is converted to a 
set of rules that can be used by the Transaction Generator 
(535). According to the present invention, transactions can 
be defined by a language called the ETE Transaction Defi- 
nition Language. This language specifies how to construct a 
transaction from events and links. The links connect one 
event to another (see FIGS. 10, U, 12 following). As 
depicted, in step 1 100, the System Administrator constructs 
a transaction definition using linked events. In step 11 50, 
once the transaction is defined by using the language it can 

j5 be translated by means of a program, similar to a parser, into 
a set tables called the transaction generation rules (540). 

The following is an example of a transaction definition. 
Here we will explain the transaction definition. Familiarity 
with FIGS. 8, 9, 11, 12, 13 is desirable to foUow this 

20 explanation. This example will also be referenced in the 
description of FIG. 14. Note that events are denoted by 
(Exy); links are denoted by (Lqr); and transaction are 
denoted by (Tde). 

Example Web Commerce Transaction Definition; 



start "> TxWebCUentGetPage (Tl) --> Link_MD_PID (L2) 
WLnsockFirstSocketOpenStart (E33) 

[liiilt_MID_PID_'nD (L3) TKWinsockGetHostByNam& (T12)] 

{lLiiik_MID_PID (L2) TxWebClientConnect (Tl)]} 

WLnsockAllSocketsClosedComplete (E20) 

T2-TxWebClientConnect -> Link_MID_PID_SocketID (L4) 

WmsockConnectStart (ElT) 

WinsockConnectCompIeU (E18) 

[liiae_Client_IP_Port (L5) TxServerAccept Cr3)] 

WmsockURLGctComplctc (E66) 

[UnK_URL^CGI TxWcbCGI (T4)] 

CloscSockctComplctc (E32) 

T4=TxWcbCGI "> liiikJvdID_ARM_Tx (L7) 

ARMLinkComplcte (ESS) 

ARMStopComplctc (E44) 

T12=TxWmsockGctHostByNainc --> Unk_JvlID_PID_nD (L3) 
WinsockGctHostByNamcStart (E21) 
WinsockGetHostByNameComplete (£22) 

Start --> T3=TxServerAccept (n) -> Link_MID_PID_SocketID (14) 
WinsockAcceptComplete (E30) 
WinsockCloseSocketComplete (E32) 



//Local 

// Local, recursive 



// Remote (no MID) 
// Remote (no MID) 



Rule Gen (920) and rely the on TxDef Script (925) as well 
as the Link Definition (950) and Transaction Definition 
(955). The Link Definition (950) relies on the Correlation 
Variable Definition (945). The RptGen Rules (81)) are 
produced by ReportGen/Rule Gen and rely on the RptDef 
Script (915) as well as the Trans. Definition (955). Note that 
the TxGenControls (545) are built from RptGenControls 
(820) and from ReportGen/Rule Gen (910). Also note that 
EventGenControls (525) are built from TxGenControls 
(545) and TransGen/Rule Gen (920). 

FIG. 7 describes an example of a flow of execution from 
the sensing of a change in state of an application until 
transactions are placed in the Transaction Store. As depicted, 
in step 1010, while the application executes, a Sensor (510) 
detects change in state and generates an event, in step 1020. 
The Agent (505) receives the event, stores it and sometimes 
forwards the event (1030) to the Processor (515). The 
Processor may generate additional events and sends them to 
the Agent (505), in step 1040. The events subscribed to by 
the Transaction Generator (535) are received by it. The 
Transaction Generator uses the Transaction Generation 



Web Commerce Transaction Explanation: 

The event starting the transaction TxWebClientGetPage is 
WinsockFirstSocketOpenStart (event E33). The last event in 

50 the transaction is E20. Those two events are linked by 
UNKL31ID_J>ID. LINie_MID_PID refers to the machine 
id (MD) and the process id (PID) of events E33 and E20. 
When the values in the (MID) and (PID) fields in those two 
events (E33 and E20) are identical, then those two events are 

55 "linked." Note that a link is written here before the two 
events it links. In this example definition, between events 
E33 and E20, two additional subtransactions can occur. One 
transaction, T12 can occur once (indicated by square 
brackets). The other transaction T2 can occur from zero to 

60 many times (indicated by {[ ]}). Those two subtransactions 
are defined as the fourth and the second subtransactions 
above. Sub trans action T2 in turn is defined in terms of two 
additional subtransactions: TxWebCGI (T4) and TxServer- 
Accept (T3). The first event of sublransaction T12 is linked 

65 to the previous event by means of LINK__MID__PID_TID 
(L3). The TID refers to a thread id. Note that the first event 
of subtransaction T12 is event E21. Thus if event E33 in 
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transaction Tl is followed by E20 with a matching UNK_ 
MID_PID, then the transaction is complete. However if 
event E33 is followed by events E21 and E22 (sec subtrans- 
action T12) with a matching UNK__MID„PID„TID and 
E33 and E21 have a matching LINK__MID_PID_TID then 
we probably have a T12 sub transaction in the Tl transaction. 
The first event of T2 is linked to the previous event by means 
of LINK__MID__PID (L2) and the parsing is done similarly. 

FIG. 9 depicts an example of a flow of execution from a 
user's request for a report or continuous monitoring until 
this request is satisfied. As depicted, in step 1200, a user 
requests a report or continuous monitoring. In step 1210, the 
Transaction Store (555) is navigated. In step 1220, transac- 
tions are retrieved from the Transaction Store (555) and 
aggregated. In step 1230, Report generation rules (810) 



VarName to VarD. The record includes three fields: iCorr- 
VarlD (1510) is the ID of the correlation variable; strCorr- 
VarName (1520) is the name of the correlation variable; and 
strCorrVarDcsc (1530) is a description of the correlation 
S variable. 

FIG. 13 depicts an example of a UNK ID Record (1600). 
This record is used to correlate events. The from event and 
the to event correlation variables are described in this record. 
It includes five fields: LinkID (1610) identifies the link; 
10 strLinkName (1620) gives the name of the link; strCon- 
VarlDFrom 1630) lists all the correlation variables in the 
"from event" (this is a "from" Corr Variable ID list); 
strCorrVarlDTO (1640) lists all the correlation variables in 
the "to event" (This a "to" Corr Variable ID list); and 
identify how to process those transactions. Finally, in step 15 strLinkDesc is a description of the link (1650). There is a 
1240, the report is produced or the GUI is updated. one to correspondence between every entry in the 

FIG, 10 depicts an example of a flow of execution during "from" list to every entry in the "to" list. 
Transaction Generation. The algorithm is similar to parsing. FIG. 14 depicts an example sequence of events encoun- 
The example browser response time and decomposition wHl tered during Transaction Generation (FIG. 10) of the Web 
also refer back to this execution flow. As discussed with lo Commerce transaction (FIG. 8). The left part of FIG. 14 
reference to FIG. 8, the Transaction Generation rules (540) describes Transaction Generation from the arriving events, 
are preferably tables that are used as an input to the The right side of FIG. 14 depicts the duration of Tl (bar on 
Transaction Generator (535). In step 1300, the Transaction the left, 1700) and the duration of T4-WebCGI (bar on the 
Generation rules (540) are loaded by the Generator as it right, 1710) that takes place on the server machine. The left 
starts. In step 1310, the Generator waits for events. When an is bar is an approximation of total response time and the right 
event arrives, in step 1320, the Generator (535) examines the bar is the server component of this response time. The 
Transaction Generation Rules (see FIG. 8 description for an network component of response time can be derived by 
example of those rules in language form) to determine subtraction. Note that only entries which have no children 
whether the event is a starting event, i.e., a new transaction. represent events. Entries having children represent transac- 
If it is, the new Transaction is then pushed into a WIP (Work 30 tions. The order of arrival of events is top down. As depicted, 
In Progress) list of Transactions and the event is indicated as a first event (13 10) "FirstSocketOpen (Start)" matches 
a starting event in this Transaction, in step 1330. If it not a transaction Tl rules (1320). The next event "by Name 
starting event in a transaction, then it is examined to (Start)" links using LINK_MID_PID_TID in transaction 
determine whether it can be linked to an event in a WIP Tl (1340, 1360). It is followed by "by Name (complete)" 
Transaction(WIPTx), in step 1340. If it can not, the process 35 (1340) to form the subtransaction "HostByName" using 
returns to wait for an event, in step 1310. If the event can be transaction definition T12 (1370, 1375). The next event 
linked to an event in a WIP Transaction, in step 1350 it is "Connect (Start)" links to "FirstSocketOpen (Start)" by 
determined whether the event is linked as a peer in this LINICJVIID JID (T2) (1340, 1360). 
Transaction. If it is a peer, in step 1360 it is bound (linked) It is then followed by "Connect (Complete)" which is peer 
to the prior event in the WIPTx. The event is then examined 40 linked to "Connect (Start) using the T2 definition (1370). 
to see whether it completes the WIPTx, in step 1380. If the The unexpanded transaction "ServerAccept" includes two 
transactions complete, in step 1390, the completed transac- events (see T3). The first event in transaction Server Accept 
tion is pushed on the stack and the process again returns to (T3) (1320, 1330) links by Link_Client_lP_Port (L5) to 
step 1310 to wait for an event. If the event does not complete "Connect (Complete)" (E18) (1340, 1360). The two unex- 
the transaction the process again returns to step 1310 to wait 45 panded events in T3: "Winsock Accept Complete" and 



for an event. If, in step 1350 it is determined that the event 
is not a peer, it is bound to an event in a WIP sub transaction, 
in step 1370. If this event completes the subtransaction, the 
sub transaction is bound to the transaction, in step 1375. 
Then process continues at step 1380. 

FIG. 11 depicts an example of an event record (1400). The 
event record includes three fields: iEventID (1410) identifies 
an event; strEventName (1420) provides the name of the 
event; and strCorrVariable (1430) is a Correlation Variable 
Definition Vector. Each entry in the Correlation Variable 
Definition Vector is a Correlation Variable ID (1510). The 
process of correlation uses the Correlation Variable Defini- 
tion Vector. When a transaction definition (see FIG. 8 
description for an example) states that two events can be 
linked to each other it specifies a LINK. The LINK will 
indicate the correlation variables that can link the events. 
The transaction generator will confirm that the two events 
indeed share the correlation variables indicated by the LINK 
and if the correlation data identified by the values of those 
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'Winsock Close Socket Complete" are generated on the 
server (1340, 1360). The next event "HTTP URL Get" (E66) 
is part of T2 (1340, 1360). It is followed by "ARM Link" 
(1320, 1330) and "ARM Stop" (1340, 1360, 1375) gener- 
ated on the server. Those form the "Web CGI" subtransaction 
(T4) as part of T2. The next event "Close Socket 
(Complete)" is the completing event in T2 (1375). T2 is now 
formed. The "All Sockets Closed (Complete)" event (E20) 
completes Tl (1340, 1360, 1390). 

FIG. 15 depicts examples of ETE APIs. The table includes 
base APIs that can generate, send, and request receipt of 
Events as well as APIs used by the Sensor (510) to establish 
communications with the Agent (505). Those skilled in the 
art will appreciate that the APIs can use one or more 
parameters (not shown) to identify characteristics (specified 
in the Functional Description) used by the API. Specifically, 
a start(parameters) API activates a specified Sensor (510) 
and establishes communications with the Agent (505). The 
makeEvent(parameters) API causes the Event Generator 



two variables are identical, it will LINK those two events. 65 (501) to create an event of a specified type with specified 
FIG. 12 depicts an example of a Correlation Variable ID attributes. The AddCorrVar(parameters) API appends speci- 
Record (1500). This record is used to translate from a fled Conelation Variable data to a specified event. The 



11/06/2003, EAST Version: 1.4.1 



6,108,700 



15 



16 



25 



sendEvent(parameters) API sends a specified event to the 
Agent (505). The deleteEvent(parameters) API deletes 
resources allocated to a specified event. The stop 
(parameters) API inactivates the Sensors and stops commu- 
nications with the Agent. The is Active(parameters) API 5 
queries the state of the Sensor, for example whether it is 
active (started) or inactive. The requestEvent(parameters) 
API solicits or cancels receipt of specified events from a 
specified supplier. 

Now that the invention has been described by way of a lO 
detailed description, various improvements, alternatives and 
equivalents will become apparent to those skilled in the art. 
Thus, it should be understood that the detailed description 
has been provided by way of an example and not as a 
limitation. The scope of the invention is properly defined by 15 
the appended claims. 

We claim: 

1. In a system wherein a client requests services involving 
a multistage computer process, a method for service level 
management of the process, comprising the steps of: 20 

defining events describing the potential stages of the 
process; 

monitoring and recording events describing the actual 

stages of the process; 
correlating and collating recorded events into one or more 

transactions describing service level attributes and the 

actual stages of the process; and 
reporting the service level attributes for one or more 

stages of the process from the one or more transactions. 

2. The method of claim 1, wherein said reporting further 
comprises the step of describing the service level attributes 
in terms of one of performance, capacity, utilization and 
availability. 

3. The method of claim 1, wherein said correlating and 
collating further comprises the step of aggregating the 
recorded events into a sub transaction associated with the 
process. 

4. The method of claim 1, wherein said reporting further 
comprises the step of aggregating multiple transactions; and 
reporting statistics for the multiple transactions. 

5. The method of claim 1, further comprising the step of 
defining a transaction as rules linking events. 

6. The method of claim 5, further comprising the steps of: 
deriving the rules from an external transaction definition; 45 
generating one or more transactions to be reported on, 

said transactions based on derived rules, 
wherein said monitoring and recording events are limited 
to events necessary for said reporting. 

7. The method of claim 1, further comprising the steps of: so 
sensors comparing a change in state against rules for 

generating events; and 
generating an event according to the rules, the event 
describing the change in state, an event identifier, a 
time stamp, and correlation data. 

8. The method of claim 1, wherein the process is a 
business transaction, further comprising the steps of: 

decomposing the business transaction into sub transac- 
tions; and 

* 60 
reporting the service level attributes associated with the 

subtransactions. 

9. The method of claim 1, further comprising the steps of: 
decomposing the process into one or more levels of 

subtransactions; and 65 
said reporting includes the step of interactively reporting 
a requested level of decomposition. 



10. The method of claim 1, for extending the measure- 
ment or reporting facilities of the system, further comprising 
the steps of: 

providing APIs and application data structures for defin- 
ing new events; 
providing a language for defining new transactions. 

11. The method of claim 1, wherein said correlating and 
collating recorded events into transactions comprises the 
steps of: 

determining if the recorded events starts the transaction 
and storing the recorded event within the transaction 
according to predefined transaction generation rules 
and controls; 

linking the recorded event to events stored within the 
transaction according to predefined transaction genera- 
tion rules and controls; 

determining if the recorded event completes the 
transaction, linking and storing the recorded event with 
the transaction; and 

storing a completed transaction in response to said deter- 
mining; wherein said reporting is in response to said 
storing. 

12. The method of claim 1, further comprising the steps 

of: 

dynamically activating a collection of additional sensor 
events and deactivating the collection of sensor events; 
said sensors generating said additional events; and 
said monitoring and recording includes monitoring and 
recording said additional events, in response to said 
generating. 

13. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 
the machine to perform method steps for a service level 
management of client requests for services involving a 
multistage computer process, said method steps comprising 
the steps of: 

defining events describing the potential stages of the 
process; 

monitoring and recording events describing the actual 

stages of the process; 
correlating and collating recorded events into one or more 

transactions describing service level attributes and the 

actual stages of the process; and 
reporting the service level attributes for one or more 

stages of the process from the one or more transactions. 

14. The program storage device of claim 13, wherein said 
reporting further comprises the step of describing the service 
level attributes in terms of one of performance, capacity, 
utilization and availability. 

15. The program storage device of claim 13, wherein said 
correlating and collating further comprises the step of aggre- 
gating the recorded events into a sub transaction associated 
with the process. 

16. The program storage device of claim 13, wherein said 
reporting further comprises the step of aggregating multiple 
transactions; and reporting statistics for the multiple trans- 
actions. 

17. The program storage device of claim 13, further 
comprising the step of defining a transaction as rules linking 
events. 

18. Hic program storage device of claim 17, further 
comprising the steps of: 

deriving the rules from an external transaction definition; 
generating one or more transactions to be reported on, 
said transactions based on derived rules, wherein said 
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monitoring and recording events are limited to events 
necessary for said reporting. 

19. The program storage device of claim 13, further 
comprising the steps of: 

sensors comparing a change in state against rules for 

generating events; and 
generating an event according to the rules, the event 

describing the change in state, an event identifier, a 

time stamp, and correlation data. 

20. The program storage device of claim 13, wherein the 
process is a business transaction, further comprising the 
steps of: 

decomposing the business transaction into subtransac- 
tions; and 

reporting the service level attributes associated with the 
subtransactions. 

21. The program storage device of claim 13, further 
comprising the steps of: 

decomposing the process into one or more levels of 

subtransactions; and 
said reporting includes the step of interactively reporting 

a requested level of decomposition. 

22. The program storage device of claim 13, for extending 
the measurement or reporting facilities of the system, further 
comprising the steps of: 

providing APIs and application data structures for defin- 
ing new events; 
providing a language for defining new transactions. 

23. The program storage device of claim 13, wherein said 
correlating and collating recorded events into transactions 
comprises the steps of: 

determining if the recorded events starts the transaction 
and storing the recorded event within the transaction 
according to predefined transaction generation rules 
and controls; 

linking the recorded event to events stored within the 
transaction according to predefined transaction genera- 
tion rules and controls; 

determining if the recorded event completes the 
transaction, linking and storing the recorded event with 
the transaction; and 

storing a completed transaction in response to said deter- 
mining; wherein said reporting is in response to said 
storing. 

24. The program storage device of claim 13, further 
comprising the steps of: 

dynamically activating a collection of additional sensor 
events and deactivating the collection of sensor events; 
said sensors generating said additional events; and 
said monitoring and recording includes monitoring and 
recording said additional events, in response to said 
generating. 

25. A computer program product comprising: 
computer usable medium having computer readable pro- 
gram code means embodied therein for a service level 
management of client requests for services involving a 
multistage computer process, the computer readable 
program code means in said computer program product 
comprising: 

computer readable program code means for defining 
events describing the potential stages of the process; 

computer readable program code means for monitoring 
and recording events describing the actual stages of the 
process; 

computer readable program code means for correlating 
and collating recorded events into one or more trans- 
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actions describing service level attributes and the actual 
stages of the process; and computer readable program 
code means for reporting the service level attributes for 
one or more stages of the process from the one or more 
5 transactions. 

26. The computer program product of claim 25, wherein 
said computer readable program code means for reporting 
further comprises computer readable program code means 
for describing the service level attributes in terms of one of 

]0 performance, capacity, utilization and availability. 

27. The computer program product of claim 25, wherein 
said computer readable program code means for correlating 
and collating further comprises computer readable program 
code means for aggregating the recorded events into a 

15 sub transaction associated with the process. 

28. The computer program product of claim 25, wherein 
said computer readable program code means for reporting 
further comprises computer readable program code means 
for aggregating multiple transactions; and reporting statis- 

20 tics for the multiple transactions. 

29. The computer program product of claim 25, further 
comprising computer readable program code means for 
defining a transaction as rules linking events. 

30. The computer program product of claim 29, further 
25 comprising: 

computer readable program code means for deriving the 

rules from an external transaction definition; 
computer readable program code means for generating 

one or more transactions to be reported on, said trans- 
30 actions based on derived rules; 

wherein said computer readable program code means for 

monitoring and recording events are limited to events 

necessary for said reporting. 

31. The computer program product of claim 25, further 
35 comprising: 

computer readable program code means for comparing a 
change in state against rules for generating events; and 

computer readable program code means for generating an 
event according to the rules, the event describing the 
40 change in state, an event identifier, a time stamp, and 
correlation data. 

32. The computer program product of claim 25, wherein 
the process is a business transaction, further comprising: 

computer readable program code means for decomposing 
45 the business transaction into subtransactions; and 

computer readable program code means for reporting the 
service level attributes associated with the subtransac- 
tions. 

33. The computer program product of claim 25, further 
50 comprising: 

computer readable program code means for decomposing 
the process into one or more levels of subtransactions; 
and 

said computer readable program code means for reporting 
55 includes computer readable program code means for 
interactively reporting a requested level of decompo- 
sition. 

34. The computer program product of claim 25, for 
extending the measurement or reporting facihties of the 

60 system, further comprising: 

computer readable program APIs and application data 

structures for defining new events; and 
computer readable program code language means for 
defining new transactions. 
65 35. The computer program product of claim 25, wherein 
said computer readable program code means for correlating 
and collating recorded events into transactions comprises: 
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computer readable program code means for determining if 
the recorded events starts the transaction and storing 
the recorded event within the transaction according to 
predefined transaction generation rules and controls; 

computer readable program code means for linking the 
recorded event to events stored within the transaction 
according to predefined transaction generation rules 
and controls; 

computer readable program code means for determining if 
the recorded event completes the transaction, linking 
and storing the recorded event with the transaction; and 

computer readable program code means for storing a 
completed transaction in response to said determining; 
wherein said reporting is in response to said storing. 
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36. The computer program product of claim 25, further 
comprising: 

computer readable program code means for dynamically 
activating a collection of additional sensor events and 
deactivating the collection of sensor events; 

computer readable program code means for generating 
said additional events; and 

said computer readable program code means for moni- 
toring and recording includes computer readable pro- 
gram code means for monitoring and recording said 
additional events, in response to said computer read- 
able program code means for generating. 
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